Operation of a CLI
As illustrated in FIG. 1, network elements typically have a text-only command line interface (CLI) that may be used for configuration and monitoring. A CLI shows the operator a prompt 100, and the operator may enter commands to cause the network element to perform various actions.
A typical CLI command 104 and response 108 is shown in FIG. 2. For example, the operator may type commands into the CLI to cause it to display alarm and status information.
The CLI is displayed in a window of fixed dimensions. Typically, as new text is displayed older commands and other displayed information move up the screen until they scroll of the top. (The invention described below is agnostic on the direction of scroll and would work fine for a system that adds new text to the top of the screen and scrolls older text off the bottom of the screen).
FIG. 3 shows the status of the screen previously shown in FIG. 2 after an operator hit the return key (at 112). Hitting enter caused the system to display a new command line prompt. When this prompt was added, the FIG. 2 prompt 100 and operator-entered command 104 has scrolled off the top of the display in FIG. 3.
Indication of Status
As shown in FIG. 2, the operator may enter a command 104 (e.g. “fault show”) and see in response a summary of the current faults. However, the operator does not have an indication that there is a fault until the appropriate command is entered. Since the operator is usually monitoring a great number of network elements, it is not practical for the operator to iteratively poll each of the network elements to see if a fault exists.
As illustrated in FIG. 4, some systems display a pop-up message 116 on the screen when an event of interest occurs. This pop-up message is delivered to the display screen without a request from the operator. Note that the pop-up message 116 will eventually scroll off the screen. Also, the pop-up message will be lost if no terminal was attached to the relevant network element at the time of the event. If a series of faults occur in close succession, then a series of pop-up messages will appear on the screen with the most recent pop-up messages pushing off all but the most recent pop-up messages.
As shown in FIG. 5, some monitoring systems for network elements use special escape code to move the cursor around the Cathode Ray Tube (CRT). These systems “freeze” part of the screen and use the frozen (non-scrolling) portion 130 of the screen to display status, while the rest of the screen continues to scroll and is used for the usual Command Line Interface. Thus, command prompts 100, operator command 120, and system response 124 will scroll in the upper section of the window.
In other words, in FIG. 5, the part of the display below the dashed line is the frozen portion 130 and does not scroll. The text “Status=OK” would be replaced by “Status=Fault” when a fault occurs. While this system is superior to systems that scroll the entire screen, the “freezing” of a portion of the screen has its own drawbacks:                The frozen portion is not available for the display of other information        Freezing requires special escape codes that vary from display to display.        Freezing interferes with the capture of the display into a log file.        Freezing can lead to extended periods of displaying the same text in the same location, which can be detrimental to certain legacy displays.        
Another way to quickly communicate network element status is via indicator lamps or LEDs. However, the use of indicators requires that the operator to be physically in the presence of the equipment. As described in more detail below, a system that relies on the operator to be in proximity with the network element is not useable in many applications.
Operational Scenarios
The following issues complicate the operation of network elements:                1. A network element will typically be one of many network elements in a network.        2. The network elements are often dispersed geographically.        3. A small number of operators will normally be monitoring a large number of network elements.        4. An issue or fault with a network element will typically affect a large number of users, so it is imperative that an operator must quickly become aware of the most severe network problems in order to diagnose and resolve any faults or issues in the network.        5. An operator may not be aware that an issue has occurred, but needs to be informed in a timely fashion.        6. The notification of the operator needs to continue as a reminder of an unresolved issue until the issue is resolved.        
Issues 1 and 2 mean that it is not practical to have a terminal attached to each network element. Rather, the TELNET protocol, IETF RFC 854, (or other suitable protocol) is used to provide a virtual connection, and the output of this connection is captured to a file for post-mortem analysis. A CLI with a frozen status area (as shown in FIG. 5) is not acceptable when logging is being performed.
Issues 3 and 4 mean that the operator must be able to quickly focus on a given network element and determine its operational status. Any hints or shortcuts provided by the network element are invaluable in leading the network operator to the most critical faults.
Issue 5 refers to the fact than an operator may be using a system without knowing a system failure has occurred, and only discovers that something is amiss when a customer complains or an operation fails. Once the operator is notified of a failure, he then conducts a lengthy search through different status displays to determine the failure reason. This sequence of steps has the potential to cause extended service outages and customer dissatisfaction.
Thus, despite the longstanding need for such a solution, the prior art has not adequately satisfied the need to provide a quick and ongoing indication of the status of a network element to an operator monitoring the status of a network element.
It is therefore an object of the invention to provide a quick and intuitive indication of network element status such as whether the network element is currently experiencing a fault condition.
It is a further object of this invention to provide such an indication of network element status through use of a system of indications that can be implemented without knowledge of the specific terminal type for the display screen used to monitor the network element or the use of escape codes.
It is a further object of this invention to provide such an indication of network element status through use of a system of indications that can be implemented without interference to a system that creates a log file of the information sent to the display monitor.